TITLE OF THE INVENTION 

Video Game Apparatus and Infonnation Storage Medium for Video Game 

BACKGROUND OF THE INVENTION 

Field of the invention 

This invention relates to a video game apparatus and a game program memory 

medium therefor, and more particularly to a video game apparatus which generates, and 

supplies to a display, an image signal to display a player object existing on a land object in 

a virtual three dimensional space by virtue of, say, player object data and land object data, 

and to a game program memory medium to be used therefor. 

Description of the prior arts 

In a conventional video game machine, when a player wishes a player object to, 

say, jump, the player presses a jump button on a controller so that the CPU causes the 
player object to jump in response to jump button operation. That is, when the player 
object is caused to jump over an obstacle, such as a hollow or hole, the player is required 
to press the jump button in timing of at a front of the hollow or hole while manipulating a 
move direction instructing means, such as a joystick or cross button. However, there may 
be a case that the player object be unsuccessful in jumping across the obstacle, as the 
timing may^be of pressing the jump button, or the player object position, in operating the 
jump button. That is, skillful operation with a jump button has been required to make the 
player object jump up and get across an obstacle. 

Meanwhile, complicated button operation has been needed to cause the player 
object to perform other actions than jump, (e.g. opening and closing a door or going up 
stairs, etc.). The player might be placed in difficulty to play a game with enjoyment of 
game progression because of his or her attention stick to button manipulation. 



Such games, called action games, is becoming more difficult to play year by year. 
They are too difficult for the player. In particular, there is a trend for beginners to 
sidestep from the games of such kind. 



SUMMARY OF THE INVEi>fnON 
Therefore, it is a primary object of the present invention to provide a novel video 
game apparatus and a program memory medium to be used therefor. 

It is another object of the present invention to provide a novel video game 
apparatus which is easy for a player to cause a player object to operate, and a game 
program memory medium to be used thereon. 

It is another object of the present invention to provide a video game apparatus with 
which a player object can get over an obstacles without difficulty, and a game program 
memory medium to be used thereon. 

It is another object of the present invention to provide a video game apparatus 
wherein it is possible for a player object, virtual camera or the like to automatically carry 
out a required operation such as jumping, camera switching or the like, and a game 
program memory medium to be used thereon. 

It is another object of the present invention to provide a video game apparatus 
which can effect complicate control with a simple program, and a game program memory 
medium to be used thereon. 

A video game apparatus according to the present invention is for generating, and 
supplying to a display, an image signal for displaying a player object existing on a land 
object in a virtual three dimensional space by processing image data for the player object 
and the land object according to a program, the video game apparatus comprising: a 
player object image data generating means for generating player object image data to 



display a player object; and a land object image data generating means for generating land 
object image data to display a land object; wherein the land object image data includes a 
program control code; the video game apparatus further comprising a program control 
code detecting means to detect the program control code in relation to a position of the 
player object, an.d an image changing means to cause the image signal to change 
depending upon the program control code detected. 

The program control code includes an action code to control an action of the 
player object, the image changing means including animation data output means to output 
animation data to automatically cause the player object to make an action in accordance 
with the action code. 

Specifically, wherein when the land object is a hollow or hole and the action code 
is "jump", the animation data output means outputting animation data to cause the player 
object to make an action of jumping over the hollow or hole. 

In one embodiment, the video game apparatus has a controller, in association 
therewith, including a direction instructing means to instruct a moving direction of the 
player object so that the player object is moved in the moving direction, the video game 
apparatus further comprising; a moving speed detecting means for detecting a moving 
speed of the player object, and a jump distance calculating means for calculating a jump 
distance of the player object based on the moving speed, the animation data output means 
outputting animation data to cause the player object to make an action of jump according 
to the jump distance. 

When the land object is a wall surface and the action code is "climb", the 
animation data output means outputs such animation data that the player object makes an 
action of climbing the wall surface. 

However, when the action code is not "climb", a wall surface height calculating 



means is further comprised to calculate a height of the wall surface, the animation data 
output means outputting such animation data that the player object makes an optimal 
action in accordance with the height of the wall surface. 

In an embodiment of the present invention, the program control code includes a 
camera control code, the image changing means including a camera control means to 
control a virtual camera provided in the three dimensional virtual space. 

Incidentally, where the virtual camera includes a plurality of virtual cameras, the 
camera control code includes a camera switching code, and the camera control means 
including a camera switching means to switch between the plurality of virtual cameras 
depending upon the camera switching code. 

Where the program control code includes a sound code, the video game apparatus 
further comprises a sound data generating means to generate sound data, and a sound 
control means to control sound to be outputted from the sound data generating means 
depending upon the sound code. 

Where the sound data generating means can generate sound data for a plurality of 
ones of sound, the sound code includes a sound switching code and the sound control 
means including a sound switching means to switch the sound data depending upon the 
sound switching code. 

Incidentally, it is possible to control only sound in accordance with a program 
control code. In this case, a video game apparatus for generating, and supplying to a 
display, an image signal to display a player object existing on a land object in a virtual 
three dimensional space by processing image data for the player object and land object 
according to a program, and further supplying a sound signal to a sound output means by 
processing sound data according to a program, the video game apparatus comprises: a 
player object image data generating means for generating player object image data to 



display a player object; and a land object image data generating means for generating land 
object image data to display a land object; wherein the land object image data includes a 
program control code; the video game apparatus further comprising a program control 
code detecting means to detect the program control code in relation to a position of the 
player object, and a sound changing means to cause the sound signal to change according 
to the program control code detected. 

Also, the video game apparatus generally uses a memory medium to previously 
memorizes a game program or image data. A memory medium according to the present 
invention is applicable to a video game apparatus for generating, and supplying to a 
display, an image signal to display a player object existing on a land object in a virtual 
three dimensional space by processing image data for the player object and the land 
object according to a program, and memorized with a program to be processed by an 
information processing means included in the video game apparatus, the memory 
medium comprising: a player object image data generating program to generate player 
object image data for displaying a player object; and a land object image data generating 
program for generating land object image data to display a land object; wherein the land 
object image data includes a program control code; and further comprising a program 
control code detecting program for detecting the program control code in relation to a 
position of the player object, and an image changing program for causing the image 
signal to change depending upon the program control code detected. 

The game program memory medium is formed with an image data area. The 
image data area is memorized with player object data and land object data. The player 
object data includes polygon data to represent a shape and animation data to represent an 
action state. The land object data includes polygon data to represent a shape, and attribute 
data. This attribute data includes a program control code including an action code, a 



camera code and a sound code. The game memory medium further includes a program to 
process image data. Tlae video game apparatus puts forward a game according to the 
image data and programs, while taking into consideration as required controller data from 
the controller. In response, on a display screen is displayed a game image having a player 
object existing on a land object in a virtual three dimensional space. 

When the player object approaches or exists on a relevant land object, a program 
control code contained in the land object image data is detected by a detecting means. 
Accordingly, the image changing means, which is different from a usual program, 
controls an action of the player object or a virtual camera. 

Where an action code is contained in the land object data representative of a land 
object at or in the vicinity of which the player object is existing, the action code is 
detected by an action code detecting means (action code detecting program). The 
animation data output means (animation data output program) output such animation data 
as to cause the player object to make an action in accordance with the detected action 
code. It is therefore possible for the player object to automatically perform an optimal 
action in compliance with the detected action code. 

Specifically, when the land object is a hollow or hole and the action code is 
"jump", the animation output means (animation data output means) outputs animation 
data to cause the player object to make an action of jumping across the hollow or hole. 

When the player object is moving according to a direction instructing means on 
the controller, the moving speed detecting means (moving speed detecting program) 
detects a moving speed of the player object while the jump distance detecting means 
Gump distance detecting program) calculates a jump distance of the player object. In this 
case, the animation data output means (animation data output program) outputs animation 
data to cause the player object to make a jump action depending upon the jump distance. 



When the Ud object is a wall surface and the action code is "climb-, the animation 
data output means (animation data output program) outputs animation data to cause the 
player object to climb a wall surface. 

If a wall surface height is calculated by a wall surface height calculating means 
(wall height detecting program), it is detennined under which range of 0 < H ^ 25. 25 < H 
. 50, 50 < H . 100 or 100 < H . 150 the wall surface height (H) falls. The animation data 

output means (animation data output program) outputs animation data to cause an optimal 

action for the wall surface height. 

Furthermore, where the program control code is a camera code, for example a 
plurality of virtual cameras properly arranged in the virtual three dimensional space is 
selectively activated by the camera code (camera switching code). 

Also, where the program control code is a sound code, for example the sound data 
to be produced by a sound data generating means is switched over. 

According to the present invention, required control can be automatically made in 
accordance with a control code contained in the land object image data, including, say, 
player object action control, image change control including virtual camera switching, 
and sound control such as sound data switching. Even in the case that a player object or a 
camera is controlled complicately in accordance with a position the player object is 
existing, it is easy to design a program. 

For example, if the program control code is an action code, it is very easy for a 
player to manipulate a player object. If the action code is "jump", the player object 
automatically jumps. Tlius, the player object can easily get across such an obstacle as a 
hole or hollow. If the action code is "climb", the player object can automatically climbing 
a wall surface. Where the action code is "door", door automatically opens and the player 
object is allowed to enter the door. Further, if the action code is "ladder", the player 



object will automatically goes up a ladder. 

The above described objects and other objects, features, aspects and advantages of 
the present invention will become more apparent from the following detailed description 
of the present invention when taken in conjunction with the accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is a schematic illustrative view showing a video game system of one 
embodiment of this invention; 

Figure 2 is a block diagram showing in detail a video game machine of the Figure 
1 system; 

Figure 3 is a block diagram showing in detail a controller control circuit of the 
Figure 2 video game machine; 

Figure 4 is a block diagram showing in detail a controller and controller pack for 
the Figure 2 video game machine; 

Figure 5 is an illustrative view showing a memory map of an external ROM for the 
Figure 2 video game machine; 

Figure 6 is an illustrative view showing a memory map of a RAM for the Figure 2 
video game machine; 

Figure 7 is a flowchart showing an overall operation of the Figure 1 embodiment; 

Figure 8 is a flowchart showing in detail a land object process in the Figure 7 
flowchart; 

Figure 9 is a flowchart showing in detail one part of an action determining process 
in the Figure 7 flowchart; 

Figure 10 is a flowchart showing in detail an action determining process for the 
case of a hole in the Figure 9 flowchart; 



Figure 11 is an illustrative view showing one example of a jump (big jump) action 
to be achieved in the Figure 10 flowchart; 

Figure 12 is an illustrative view showing one example of a jump (middle jump) 
action to be achieved in the Figure 10 flowchart; 

Figure 13 is an illustrative view showing one example of a jump (small jump) 
action to be achieved in the Figure 10 flowchart; 

Figure 14 is an illustrative view showing one example of a «not-fall" action in the 
Figure 10 flowchart; 

Figure 15 is a flowchart showing in detail an aaion determining process for the 
case of a wall surface in the Figure 9 flowchart; 

Figure 16 is an illustrative view showing one example of a wall scramble up action 
to be achieved by the Figure 15 flowchart; 

Figure 17 is a flowchart showing one example of a step mounting action to be 
achieved by the Figure 15 flowchart; 

Figure 18 is an illustrative view showing a jump up action to be achieved by the 
Figure 15 flowchart; 

Figure 19 is an illustrative view showing one example of a light climb action to be 
achieved by the Figure 15 flowchart; 

Figure 20 is an illustrative view showing one example of a usual climb action to be 
achieved by the Figure 15 flowchart; 

Figure 21 is an illustrative view showing one example of a hard climb action to be 

achieved by the Figure 15 flowchart;. 

Figure 22 is a flowchart showing in detail a door action in the Figure 9 flowchart- 
Figure 23 is an illustrative view showing one example of a door action to be 

achieved by the Figure 22 flowchart; 



Figure 24 is a flowchart showing in detail a ladder action in the Figure 9 flowchart; 
Figure 25 is an illustrative view showing one example of a ladder action achieved 
by the Figure 24 flowchart; 

Figure 26 is a flowchart showing in detail a player object process in the Figure 7 
flowchart; 

Figure 27 is an illustrative view showing in detaU a camera determining process in 
the Figure 7 flowchart; 

Figure 28 is an iUustrative view showing one example of camera arrangement as a 
premise for the camera determining process of Figure 27 flowchart; 

Figure 29 is a flowchart showing in detail a first camera control program in the 
Figure 27 flowchart; 

Figure 30 is an illustrative view showing a player object taken by a first camera 
according to the Figure 29 flowchart; 

Figure 31 is a flowchart showing in detail a second camera (fifth camera) control 
program in the Figure 27 flowchart; 

Figure 32 is a flowchart showing in detail a third camera control program of the 
Figure 27 flowchart; 

Figure 33 is an illustrative view showing a player object taken by the third camera 
according to the Figure 32 flowchart; 

Figure 34 is a flowchart showing in detail a fourth camera control program in the 
Figure 27 flowchart; 

Figure 35 is an illustrative view showing a player object taken by a fourth camera 
according to the Figure 34 flowchart; 

Figure 36 is an illustrative view showing a player object taken by the fourth 
camera according to the Figure 32 flowchart; and 
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Figure 37 is a flowchart showing in detail a sound process in the Figure 7 
flowchart. 

DETAILED DESCRIPTION OF THE PREFFERED EMBODIMENTS 

Referring to Figure 1, a video game apparatus in this embojliment includes a video 
game machine 10, a ROM cartridge 20 as one example of an information memory 
medium, a display unit 30 connected to the video game machine 10, and a controller 40. 
The controller 40 is dismountably mounted with a controller pack 50. 

The controller 40 is structured by a plurality of switches or buttons provided on the 
housing 41 in a form graspable by both or one hand. Specifically, the controller 40 
includes handles 41L, 41C, 41R downwardly extending respectively from a left end, a 
right end and a center of the housing 41, providing an operation area on a top surface of 
the housing 41. In the operation area, there are provided an analog-inputtable joystick 
(hereinafter referred to as "analog joystick") 45 at a central lower portion thereof, a 
cross-shaped digital direction switch (hereinafter called "cross switch") 46 on the left 
side, and a plurality of button switches 47A, 47B, 47D, 47E and 47F on the right side. 

The analog joystick 45 is used to input a moving direction and/or moving speed or 
moving amount of the player object (object to be operated by a player through a 
controller) as determined by an amount and direction of joystick mclination. The cross 
switch 46 is used to designate a moving direction of the player object,.in place of the 
joystick 45. The button switches 47 A and 47B are used to designate a motion of the 
player object. Button switches 47C - 47D are used to switch over a visual point of a 
three-dimension image camera or adjust speed or the like of the player object. 

A start switch 47S is provided almost at a center of the operation area. This start 
switch 478 is operated when starting a game. A switch 47Z is provided at a backside of 
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the central handle 41C. This switch 47Z is utilized, for example, as a trigger switch in a 
shoot game. Switches 47L and 47R are provided at upper left and right of a lateral surface 
of the housing 41. 

Incidentally, the above-stated button switches 47C - 47F can also be used to 
control the motion and/or moving speed (e.g. acceleration or deceleration) of the player 
object in a shoot or action game, besides for the purpose of switching the camera visual 
pomt. However, these switches 47A - 47F, 47S. 47Z, 47L and 47R can be arbitrarily 
defined in their function depending upon a game program. 

Figure 2 is a block diagram of the video game system of the Figure 1 embodiment. 
The video game machine 10 incorporates therein a central processing unit (hereinafter 
referred to as "CPU") 11 and a coprocessor (reality coprocessor: hereinafter referred to as 
"RCP") 12. The RCP 12 includes a bus control circuit 121 for controlling buses, a signal 
processor (reality signal processor; hereinafter referred to as "RSP") 122 for performing 
polygon coordinate transformation, shading treatment and so on, and a rendering 
processor (reality display processor; hereinafter referred to as "RDP") 46 for rasterizing 
polygon data into an image to be displayed and converting the same into a data form (dot 
data) memorable on a frame memory. 

The RCP 12 is connected with a cartridge connector 13 for unloadably loading a 
ROM cartridge 20 having an external ROM 21 incorporated therein, a disc-drive 
connector 197 for detachably mounting a disc drive 29, and a RAM 14. Also, the RCP 12 
is connected with DAC (Digital'Analog Converters) 15 and 16 for respectively outputting 
a sound signal and video signal to be processed by the CPU 11. Further, the RCP 12 is 
connected with a controller control circuit 17 to serially transfer operating data on one or 
a plurality of controllers 40 and/or controller pack 50. 

The bus control circuit 121 included in the RCP 12 perfonns parallel/serial 



conversion on a command suppUed in a parallel signal from the CPU via a bus, to thereby 
supply a serial signal to the controller control circuit 18. Also, the bus control circuit 121 
converts a serial signal inputted from the controller control circuit 17 into a parallel 
signal, giving an output to the CPU 11 via the bus. The data representative of an 
operating state (operating signal or operating data) read out of the controller 40A - 40D is 
processed by the CPU 11, and temporarily stored within a RAM 14, and so on. In other 
words, the RAM 15 includes a storage site for tempomrily memorizing the data to be 
processed by the CPU 11, so that it is utilized for smoothly reading and writing data 
through the bus control circuit 121. 

The sound DAC 15 is comiected with a comiector 19a provided at a rear face of the 
video game machine 10. The video DAC 16 is comaected with a comiector 19b provided 
at the rear face of the video game machine 10. The comiector 19a is comiected with a 
speaker 31 of a display 30, while the comiector 19b is comiected with a display 30 such as 
a TV receiver or CRT. 

The controller control circuit 17 is comiected with a controller connector provided 
at the front face of the video game machine 10. TTie comiector 18 is discomiectably 
comiected by a controller 40 through a comiecting jack. Hie comiection of the controller 
40 to the comiector 18 places the controller in electrical comiection to the video game 
machine 10, thereby enabling transmission/reception or transfer of data therebetween. 

The controller control circuit 17 is used to transmit and receive data in serial 
between the RCP 12 and the comiector 18. The controller control circuit 17 includes, as 
shown in Figure 3, a data transfer control circuit 171, a transmitting circuit 172, a 
receiving circuit 173 and a RAM 174 for temporarily memorizing transmission and 
reception data. The data transfer control circuit 171 includes a parallel/serial converting 
circuit and a serial/parallel converting circuit in order to convert a data format during data 



transfer, and further performs write/read control on the RAM 174. The serial/parallel 
■ converting circuit converts the serial data supplied from the RCP 12 into parallel data, 
supplying it to the RAM 174 or the transmitting circuit 172. The parallel/serial 
converting circuit converts the parallel data supplied from the RAM 174 or the receiving 
circuit 173 into serial data, to supply it to the RCP 12. The transmitting circuit 172 
converts the command for reading signals from the controller 40 and the writing data 
(parallel data) to the controller pack 50, into serial data to be delivered to channels CHI - 
CH4 corresponding to the respective controllers 40. The receiving circuit 173 receives, in 
serial data, operational state data of the controllers inputted through corresponding 
channels CHI - CH4 and data read from the controller pack 50, to convert them into 
parallel data to be delivered to the data transfer control circuit 171. The data transfer 
control circuit 171 writes into the RAM 174 data transferred from the RCP 12, data of the 
controller received by the receiving circuit 183, or data read out of the RAM controUer 
pack 50, and reads data out of the RAM 174 based on a command from the RCP 12 so as 
to transfer it to the RCP 12. 

The RAM 174, though not shown, includes memory sites for the respective 
channels CHI - CH4. Each of the memory sites is stored with a command for the 
channel, transmitting data and/or reception data. 

Figure 4 is a detailed circuit diagram of the controller 40 and the controller pack 
50. The housing of the controller 40 incorporates an operating signal processing circuit 
44, etc. in order to detect an operating state of the joystick 45, switches 46, 47, etc. and 
transfer the detected data to the controller control circuit 17. The operating signal 
processing circuit 44 includes a receiving circuit 441, a control circuit 442, a switch 
signal detecting circuit 443, a counter circuit 444, a joyport control circuit 446, a reset 
circuit 447 and a NOR gate 448. The receiving circuit 441 converts a serial signal, such 
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as a control signal transmitted from the controller control circuit 17 or writing data to the 
controller pack 50, into a parallel signal to supply it to the control circuit 442. The control 
circuit 442 generates a reset signal to reset (0), through the NOR gate 448. count values of 
an X-axis counter 444X and a Y-axis counter 444Y within the counter 444, when the 
control signal transmitted from the controller control circuit 17 is a signal for resetting X, 
Y coordinates of the joystick 45. 

The joystick 45 includes X-axis and Y-axis photo-interrupters in order to 
decompose a lever inclination into X-axis and Y-axis components, generating pulses in 
number proportional to the inclination. The pulse signals are respectively supplied to the 
counter 444X and the counter 444Y. The counter 444X counts a number of pulses 
generated in response to an inclination amount when the joystick 45 is inclined in the X- 
axis direction. The counter 444Y counts a number of pulses generated responsive to an 
inclination amount when the joystick 45 is inclined in the Y-axis direction. Accordingly, 
the resultant X-axis and Y-axis vector determined by the count values of the counters 
444X and 444Y serves to determine a moving direction and a coordinate position of the 
player object or hero character or a cursor. Incidentally, the counter 444X and the 444Y 
are reset, when a reset signal is supplied from the reset signal generating circuit 447 upon 
turning on the power or a reset signal is supplied from the switch signal detecting circuit 
443 by simultaneous depression of predetermined two switches. 

The switch signal detecting circuit 443 responds to a switch-state output command 
supplied at an interval of a constant period (e.g. a 1/30 second interval as a TV frame 
period) from the control circuit 442, to read a signal varying depending upon a depression 
state of the cross switch 46 and the switches 47A - 47Z. The read signal is delivered to 
the control circuit 442. The control circuit 442 responds to a read-out command signal of 
operational state data from the controller control circuit 17 to supply in a predetermined 
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data format the operational state data on the switches 47A - 47Z and count values of the 
counters 444X and 444Y to the transmitting circuit 445. The transmitting circuit 445 
converts the parallel signal outputted from the control circuit 442 into a serial signal, and 
transfer it to the controller control circuit 17 via a converting circuit 43 and a signal line 
42. The control circuit 442 is comiected with a joystick control circuit 446 via an address 
bus and a data bus as well as a port comiector 46. The joyport control circuit 446 
performs data input/output (or transmission/reception) control according to a command 
from the CPU 11 when the controller pack 50 is connected to the port connector 46. 

The controller pack 50 is structured by connecting the RAM 51 to the address bus 
and data bus and connecting the RAM 51 with a battery 52. The RAM 51 is to store 
backup data in relation to a game, and saves backup data by the application of electric 
power from the battery 52 even if the controller pack 50 is withdrawn from the port 
connector 46. 

Figure 5 is a memory map illustrating a memory space of an external ROM 21 
incorporated in the ROM cartridge 20 (Figure 1, Figure 2). The external ROM 21 
includes a plurality of memory areas (may be hereinafter referred merely to as "areas"), 
i.e., a program area 22, an image data area 23 and a sound memory area 24, which are 
memorized previously and fixedly with various programs. 

The program area 22 is memorized with a program required to process game 
images, game data suited for a game content, etc. Specifically, the program area 22 
includes memory areas 22a - 22i to previously, fixedly memorize a CPU lloperation 
program. A main program area 22a is memorized with a main routine processing 
program for a game shown in Figure 7, etc., hereinafter referred to. A controller data 
determining program area 22b is memorized with a program to process controller 40 
operation data. A land object program area 22c is memorized with a program to display 
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and control a land object on or in the vicinity of which the player object is to exist. A 
player object program area 22d is memorized with a program to display and control an 
object to be operated by a player (referred merely to as "player object"). 

The program area 22 further includes a control code detecting program area 22e. 
On this area 22e is installed a program to detect a control code contained in land object 
image data (hereinafter referred to). A camera control program area 22f is memorized 
with a camera control program to control in which direction and/or position a moving 
object, including the player object, or background object is to be taken in a three 
dimensional space. In the embodiment a plurality of virtual cameras are installed in a 
three dimensional space. Accordingly, the camera control program area 22f includes a 
first camera control program, second camera control program, Nth camera control 
program to individually control respective ones of first to Nth virtual cameras. 

An action control program area 22g is memorized with a program to read out 
animation data contained in the player object image data, in order to cause the player 
object to act according to a control code detected by a control code detecting program. 
The action control program, concretely, includes various calculation programs. The 
calculation programs include a moving speed detecting program to detect a moving speed 
of the player object, a jump distance calculating program to calculate a jump distance of 
the player object based on a moving speed, and a wall height calculating program to 
calculate a wall height. This action control program determines an action for the player 
object according to an action code, control code or calculation program, arid reads 
animation data out of the image data area 23 depending upon an action. Accordingly, the 
action control program 22g cooperates with the image data area 23 to thereby constitute 
an animation data output program. 

An image buffer and Z buffer write program area 22h is memorized with a write 
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program by which the CPU 11 causes the RCP 12 to effect writing onto an image buffer 
and a Z buffer. For example, the write program area 22h is memorized with a program to 
write color data to the frame memory area (Figure 6) of the RAM and a program to write 
depth data to the Z buffer area 204 (Figure 6), as image data based on texture data for a 
plurality of moving objects or background objects to be displayed on one background 
scene. 

Incidentally, a sound process program area 22i is memorized with a program to 
generate a message through effect sound, melody or voices. 

The image data area 23 includes, as shown in Figure 5, two memory areas 23a and 
23b. The memory area 23a is memorized with image data, such as coordinate data and 
animation data of a plurality of polygons, on an object-by-object basis, in order to display 
a player object, and with a display control program to display in a predetermined fixed 
position or movably an object. The memory area 23b is memorized with image data, such 
as a plurality of ones of polygon data and attribute data, on an object-by-object basis to 
display a land object, and with a display control program to display a land object. The 
attribute data includes an action code representative of an action to be performed by the 
player object (say, jump, wall scramble, door open and close, ladder climb, etc), a kind 
code representative of a kind of a land polygon (hole, ice, sand, lava, etc), a melody code 
representative of a kind of BGM, an enemy code representative whether an enemy is 
existing or not and an enemy kind, and a camera code to instruct switch between cameras. 
These codes are collectively referred to as "control codes". The control codes have been 
previously set within the polygon data of every polygon constituting the land objects to be 
set. Incidentally, the land objects required are considered to include a land object on 
which the player object is to exist, and a land object in the vicinity of which the player 
object is to exist, and so on. 



- 18- 



A sound memory area 24 is memorized with sound data, such as phrases, effect 
sound and game melody, for each scene to output a message as above in a manner suited 
for a relevant scene. Specifically, BGMl and BGM2 are memorized as a game melody, 
and sound data such as "outcry" as an effect sound. 

Incidentally, the memory medium or external memory may use an arbitrary 
memory medium, such as a CD-ROM or magnetic disc, in place of or in addition to the 
ROM cartridge 20. In such a case, a disc drive (not shown) should be provided in order to 
read, or write as required, various ones of data for a game (including program data and 
image display data) from the optical or magnetic disc-formed memory medium, such as a 
CD-ROM or magnetic disc. This disc drive reads out data memorized on the magnetic 
disc or optical disc which is magnetically or optically memorized with similar program 
data to that of the external ROM 21, and transfers the data to the RAM 14. 

In this manner, the program area 22 is installed with the programs so that a game 
image signal can be created by processing the image data set on the image data area 23 in 
a manner similar to the conventional video game apparatus, and a sound signal can be 
produced by processing the sound data installed on the sound memory area 24. In this 
embodiment, furthermore, a program control code is previously set on the image data 
memorized in the image data area 23, say, in the land object image data. When the 
program control code is detected in dependence upon a position of the player object, the 
animation for the player object is varied, the virtual camera is switched over and further 
the sound signal is changed in compliance with a detected program control code. Thus, 
the program control code serves as a program control factor or program change factor. 

Due to this, if when a program code is detected the player object is changed in 
animation or the camera is switched over, it is possible to provide image change in a 
manner different from that by the execution of a usual program. Also, if when a program 
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control code is detected the sound signal is switched over, it is possible to cause a 
different sound change from that by executing an ordinary program. 

Incidentally, the control code is explained with greater detail. As mentioned 
above, the land object data includes attribute data, wherein the control code is included in 
the attribute data. The attribute data is a predetermined number of bits of data 
representative of what the present land object is, say, a kind of an object, such as a hole, 
floor, wall surface, stair, grassy land or the like. Therefore, the CPU 11 can determine a 
kind of a land object by detecting attribute data. 

The control code is configured by 1 or 2 or more bits in attribute data. The 
attribute data is included within each polygon to constitute a land object. As a result, the 
control data is included in each polygon. The control code represents, by 1 or 2 or more 
bits, a control content, say, "jump", "climb", "enter door", "ladder", "camera switch", 
"sound switch", etc. 

Incidentally, in the above e.xpIanation, a kind of a land object was detennined by 
referring to attribute data. However, the method for detecting a land object may be as 
follows. For e.xample, a land object on which the player object is moving may be detected 
as a floor object whereby a land object provided at 90 degrees (vertically) with respect to 
the floor object is detected as a wall or wall surface object. In this case, a land object 
existing at above the player object will be detected as a ceiling object. That is, a kind of a 
land object may be determined by a positional relationship, angle or the like relative to the 
player object. 

In either case, a program control code (including a control code, action code, 
camera code, sound code, and so on) is set in attribute data. 

Figure 6 is a memory map illustrating an entire memory space of the RAM 14. 
The RAM 14 includes various memory areas 201 - 209. For example, the RAM 14 
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includes a display list area 201, a program area 202, a frame memory (or image buffer 
memory) area 203 for temporarily memorizing 1 frame of image data, a Z buffer area 204 
for memorizing, dot by dot, depth data of the frame memory area data, an image data area 
205, a sound memory area 206, an area 207 for memorizing controller operation state 
data, a working memory area 208, and register/flag area 209. The memory areas 201 - 
209 are memory spaces to be accessed through the bus control circuit 121 by the CPU 11 
or directly by the RCP 12, and assigned with an arbitrary capacity (or memory space) by 
a game used. Meanwhile, the image data area 205 and the sound memory area 206 are to 
temporarily memorize image data or sound data required to execute a program transferred 
to the program area 202, which program is a part of data of game programs for 1 game 
entire scene (stage) memorized in the memory area 22 of the ROM 21, e.g. a game 
program required for 1 course or stage. In this mamier, if the program required for a 
certain scene or data part are memorized in the memory areas 202, 205, 206, it is possible 
to enhance data processing efficiency and hence image processing speed as compared to 
the processing by directly reading from the ROM 21 each time the CPU requires. 

Specifically, the frame memory area 203 has a memory capacity corresponding to 
the number of picture elements (pLxels or dots) of the display 30 (Figure 1) X the number 
of bits of color data per pLxel, to memorize color data dot by dot corresponding to the 
pixels on the display 30. The frame memory area 203 temporarily memorizes color data 
dot by dot when displaying a moving object; such as a player object, fellow object, enemy 
object, boss object etc. or various other objects such as a land object, background (or 
stationary) object, etc. that are memorized in the image data area 105. 

The Z buffer area 204 has a memory capacity corresponding to the number of 
picture elements (pixels or dots) of the display 30 X the number of bits of depth data per 
pixel, to memorize depth data dot by dot corresponding to each pixel on the display 30. 



The Z buffer area 204 temporarily memorizes depth data dot by dot when displaying a 
moving and/or stationary object, i.e. a moving object such as a. player object, fellow 
object, enemy object, boss object or the like, and various other objects such as a land, 
object, background (or stationary) object or the like that are memorized in the image data 
5 area 205. 

The- image data area 205 is to memorize coordinate data and texture data for 
polygons to be constituted in a plurality of sets for each of stationary and/or movable 
objects for game display memorized in the ROM 21, to which 1 course or stage of data, 
for example, is transferred from the ROM 21 in advance of their image processing. 

10 Incidentally, this image data area 205 also memorizes animation data that has been read 
out, as required, from the image data area 23 of the external ROM 21. 

The sound memory area 206 is transferred by part of the sound data (data of 
phrase, melody and effect sound) memorized in the memory area of the ROM 21, and 
temporarily memorize it as sound data to be produced through a sound producing unit 32. 

15 The controller data (operation state data) memory area 207 temporarily 

memorizes operation state data representative of an operation state read from the 
controller 40. 

The working memory area 208 temporarily memorizes data such as parameters 
during execution of a program by the CPU 11. 
20 The register/flag area 209 includes register area 209r and flag area 209f. The 

register area 209r, though not shown, is formed with a plurality of registers to be 
individually loaded with data. The register area 209r, though not shown, is formed with a 
plurality of flags to be separately set or reset. 

Figure 7 is a main flowchart of the video game system in this embodiment. If a 
25 power is turned on, in a first step SI, the CPU 11 at a start sets the video game machine 10 
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in a predetermined initial state. For example, the CPU 11 transfers a starting program of 
the game programs memorized on the program area 22 of the external ROM 21 to the 
program area 202 of the RAM 14, and sets parameters to their initial values, executing 
sequentially steps of Figure 7. 
5 The operation of the main flowchart of Figure 7 is carried out, for example, at an 

interval of 1 frame (l/60th second) or 2 or 3 frames. The steps S2 - S12 are repeatedly 
executed until the course has been cleared. If the game comes over without successfully 
clearing the course, in step S14 following step S13 a game over process is performed. If 
the course clear is successful, the process returns from the step S12 to the step SI. 

10 That is, in the step SI is displayed a game course screen and/or course selecting 

screen. However, if the game is started after turning on the power, a screen of first course 
is displayed. If the first course is cleared, a next course is set up. 

In the step S2 following the step SI is carried out a controller process. In this 
process, detection is made on which one was operated of the joystick 45 of the controller 

15 40, cross switch 46 and switches 47A - 47Z. The operation state detection data 

(controller data) is read in, and the controller data thus read is written onto the controller 
data area 141 of the RAM 14. 

In the step S3 a land object process is performed. This process, though hereinafter 
explained in detail with reference to a subroutine of Figure 8, includes a calculation of a 

20 land object display position and shape based on a program partly transferred from the 

memory area 22c and land object polygon data transferred from the memory area (Figure 
5). 

In the step S4 a process is executed to determine an action for the player object. 
Concretely, as explained hereinafter with reference to Figure 9 to Figure 26, 
25 determination is made on an action for the player object according to a control code or 
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action code explained before. 

In step S5 a process is performed to display a player object. This process is 
basically a process to cause changes in position, direction, shape and location on the basis 
of a joystick 45 operating state (controller data) operated by a player and the presence or 
absence of enemy attack. For example, the polygon data after change is determined by 
calculation based on the program transferred from the memory area 22e (Figure 5) of the 
external ROM 21, the player object polygon data transferred from the memory area 23a, 
and the controller data, i.e. joystick 45 operating state. Colors are given by texture data to 
a plurality of polygons obtained by the above. 

The step S6 is a step to carry out a camera determination process. In concrete, it is 
determined which virtual camera of a plurality of virtual cameras is to be used in taking 
pictures of an object in a virtual three dimensional space, according to a switch code 

(control code) contained in land object data explained before. This will be hereinafter 

explained in detail with reference to Figure 27 to Figure 36. 

In the step S7 a camera process is carried out. For example, a coordinate of a 

visual point to the object is calculated such that a line or field of sight as viewed through a 

viewfinder of the virtual camera comes to an angle designated through the joystick 45 by 

the player. 

In the step S8 the RSP 122 performs a rendering process. That is, the RCP 12 
under the control of CPU 11 performs transformation (coordinate transformation and 
frame memory rendering) on the image data to display a movable object and stationary 
object based on the texture data for the movable object, such as an enemy object, player 
object, or the like, and the stationary object, such as for background, memorized in the - 
image data area 201 of the RAM 14. Specifically, colors are given to a plurality of 
polygons for each of a plurality of movable objects and stationary objects. 
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In the step S9, the CPU 1 1 performs a sound process based on sound data, such as 
messages, melody, effect sound, etc. In particular, BGM and the like are switched over 
according to a melody code (control code) previously set in the land object, as shown in a 
subroutine of Figure 37. 

In the next step SIO the CPU 11 reads out image data memorized on the frame 
memory area 203 of the RAiM 14, according to a result of the rendering process of the step 
S7. Accordingly, a player object, moving object, stationary object and enemy object, and 
the like are displayed on a display screen of the display 30 (Figure 1, Figure 2). 

In the step S 11, the RCP 12 reads out the sound data obtained as a result of the 
sound processing of the step S18, thereby outputting sound such as melody, effect sound, 
conversation, etc. 

In the step S12 whether the course was cleared or not is determined (course clear 
detection). If the course was not cleared, it is determined in the step S13 whether the 
game is over or not. If not game over, process returns to the step S2 to repeat the steps S2 
- S13 until a condition of game over is detected. If a game over condition is detected, i.e. 
the number of mistakes permitted for the player reaches a predetermined number of times 
or the life of player object is consumed by a predetermined amount, then in the step S14 is 
effected a game over process, such as a selection of game play continuation or backup 
data memorization. 

Incidentally, in the step S 12 if a condition of clearing the course (e.g. defeating a 
boss, etc.) is detected, the course clear process is carried out and thereafter the process 
returns to the step SI. 

Figure 8 is a subroutine of the land object process shown in the step S3 of Figure 7; 
In a first step 301, the CPU 11 (Figure 2) reads out polygon data, or a land object required 
at that time, transferred from the image data area 23 (Figure 5) of the external ROM 21 to 



the image data area 205 (Figure 6) of the internal RAiM 14. This polygon data has a 
control code previously set as required therein, as was explained before. Accordingly, if 
the step S301 is executed, the same control data is simultaneously read out. Incidentally, 
the read polygon data containing a control code (action code, camera switch code, sound 

code or the like) is temporarily held in a display Ust area 201 of the internal RAM 14. 
In step S302 texture data is read out which corresponds to the land object and 

transferred to the image data area 205 of the internal RAM 14. In step S303 camera data 

is similarly read out of the image data area 205 which corresponds to that land object. 

These texture data and camera data are memorized on the display list area 201, similarly 

to the polygon data. 

Then, in step S304 the land object is memorized in the display list area 201. It is 
determined in step S305 whether the process of from the step S301 to the step S304 has 
been e.xecuted on all the land objects or not. If the determination is "NO", the process is 
again executed from the step S301. If all the land objects has been completed of the 
process, i.e. if "YES" is determined, the subroutine of Figure 8 is ended and the process 
returns to the main routine. 

The action determination process in the step S4 of Figure 7 is carried out, 
concretely, according to a flowchart shown in Figure 9. That is, in the first step S401 the 
CPU 11 (Figure 2) detects a state of the player object. That is, whether the player object is 
in any action or not is detected. If the player object is in a course of an action, "YES" is 
determined in step S402, and the process advances to the succeeding step S403. 

In the step S403 the CPU 11 makes reference to the register/flag area 209 of the 
RAM 14 shown in Figure 6, and detects a control code or action code contained in the 
object data of a land object existing at the foot of the player object. The control code or 
action code, as was explained before, has been previously set within the land object area 
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23b of the external ROM 21 shown in Figure 5, and previously transferred to the image 
data area 205. The land object data is read onto the display list area 201 every frame. 
Consequently, the CPU 1 1 detects an action code in the display list area 201. 

Subsequently, the CPU 11 in step S404 detects whether the player object is in 
falling or not. That is, the player object is determined in action in the preceding step 
S402, and it is determined that the action is "fall" action or not. 

If the player object is in falling, then the CPU 11 in the next step S405 detects a 
height of the player object at that time from the land object. The CPU 11 in step S406 
determines that the player object should make a landing when the height of the player 
object from the land object is at a predetermined height, i.e. the height is sufficiently low. 
At this time, the CPU 1 1 in the next step S407 causes the player object to begin a landing 
action. 

That is, the CPU 11 in this step S407 causes the player object to change in form 
based on landing-action animation data memorized in the player object data area 23a of 
the external ROM 201, and control the RCP 12 to write color data to the frame memory 
area 203. Incidentally, this animation data is data representative of movement in skeleton 
of player object. The player object is to be displayed by a combination of the animation 
data and the polygon data, similarly to the objects. Accordingly, even with same polygon 
data if animation data is different, the player object changes in action. Due to this, in this 
step S407 by reading out animation data for "landing action" the player object can be 
caused to make a landing action. 

If it is determined in the previous step S402 that the player object action state is not 
"in the course of an action", the CPU 11 in step S408 detects a control code or action code' 
for a land object existing nearby (in front or at the foot of) the player object from the 
display list area 201, similarly to the step S403. In the next step S409, the CPU 11 makes 
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reference to the attribute data of the land object at the foot of the player object, thereby 
determining whether the land object is a "hollow" or "hole". Alternatively, the land 
object at that time is a hollow or hole may be determined from that there is a floor object 
located at zero degree (parallel or horizontal) with respect to a moving direction of the 
player object and the floor object is formed with a downward step. 

Where the land object is a "hollow" or "hole", the CPU in the succeeding step 
S410 executes a "hole action" subroutine shown in Figure 10. If "NO" is determined in 
the step S409, then it is determined in step S411 whether the land object is "wall surface 
or not by the attribute code. However, as stated before, a wall surface object may be 
detected by an angle (90 degrees) with respect to the player object advancing direction or 
the floor object. If the land object is a "wall surface", the CPU 11 in the succeeding step 
S412 executes a "wall surface action " subroutine shown in Figure 16. If "NO" is 
determined in the step S411, then it is determined in step S413 whether the land object is 
a "door" by the attribute code or an angle to the floor object. Where the land object is a 
"door", CPU in the succeeding step S414 executes a "door action" subroutine shown in 
Figure 23. If "NO" is determined in the step S413, then it is determined in step S415 
whether the land object is a "ladder" or not by the attribute code or by an angle to the floor 
object. Where the land object is a "ladder" the CPU 11 in the succeeding step S416 
executes a "ladder action" subroutine shown in Figure 25. 

Explanation is herein made on a "hole action" with reference to Figure 10 as well 
as Figure 11 to Figure 15 related thereto. In the first step S417 of Figure 10, reference is 
made to the display list area 201 (Figure 6) to detect an action code or control code for the 
land object at the foot of the player object in front of the hole. More specifically, if the 
attribute data of a floor object constituting a "hole" includes 1 or 2 bits or more of a 
control code and the control code is "0", the control code is set as default to 'Mump". 
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Meanwhile, the control codes of a floor object constituting a hole includes, besides this, 
"bottomless pit", "scene switching", "not-fall", "step off' and so on. 

If the control code or action code detected in step S418 is not a "not-fall" code, i.e., 
where the control code or action code is "jump", "NO" is determined in the step S418. 
The CPU 11 in the next step S419 determines a height of the player object at that time 
from a land object, in a similar manner to the previous step S405. 

It is detennined in step S420 whether the calculated height of the player object is 
lower than a predetermined height, e.g. "200 cm", or not. It is noted that "cm" is by a 
virtual length unit within a virtual three dimensional space, as applied to the hereunder. If 
"NO" is detennined in this step S420, the CPU 11 in the next step S421 calculates a 
moving speed of the player object at that time. In step S422 the CPU 11 calculates a 
distance over which the player object is to jump based on the height calculated in the step 
S419 and the speed calculated in the speed S421. In the next step S423 the action of a 
jump is started according to the jump distance. 

Figure 11 shows one example of such a jump action that the player object can 
jump across a hole to an opposite bank because of a short distance LI of the hole. Figure 
12 shows one example of such a jump action that because the hole is somewhat long in 
distance L2 the player object cannot jump across the hole but can lay his hand on the 
opposite bank. Figure 13 shows one example of such a jump that the hole distance L3 is 
too long for the player object to jump across the hole or to lay his hand on the opposite 
bank resulting in fall into the hole. In any of the cases, a jump action required is 
automatically effected according to a jump code contained in a land object existing 
thereon. 

The distance that the player object can jump across is correlated to a moving speed 
of the player object. That is, if the player object is running fast, it can jump across a large 
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hole alike the distance L. However, when the player object is moving by walk, there may 
be a case that the player object camaot jump across the hole even if the control code 
"jump" has been set. Consequently, when the player object is walking, the player object 
may not jump across but fall into the hole or may be going to fall into a hung position with 
only the hand laid on the opposite cliff. 

Such jump actions can be achieved by reading corresponding animation data from 
the player object data area 23a of the external ROM 221, as was explained before. 

Incidentally, if "YES" is determined in the step S418, i.e. if the control code or 
action code of a land object in front of the hole is a "not-fall" code, the CPU 11 in step 
S424 causes the player object to begin an action of not-fall. In this case, the player object 
is going to fall into the hole but assumes a position of being hung down with only the 
hand laid on the opposite cliff. 

xMeanwhile, if in step S420 the height of the player object is determined less than 
200 cm, it is determined that no jump should be effected. In step S425 the CPU 11 starts 
the player object to make an action to fall. That is, if the height or depth of the hole is 
greater than 200 cm (virtual length), a jump action as mentioned above is executed. If 
less than 200 cm, the player object is caused to move walking into the hole as it is without 
jump as shown in Figure 14. 

If "NO" is determined in the step S409, in step S41 1 attribute data or an angle is 
referred to, thereby determining a kind of a land object is a "wall surface" or not. If 
"YES" is determined in this step S411. the CPU 11 in step S412 starts an action "wall 
surface action" which is to be made when the player object is faced with a wall surface. 
This wall surface action is executed, concretely, according to a flowchart shown in Figure 
15. 

In the first step S426 of Figure 15, the CPU 1 1 determines whether or not a control 
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code or action code contained in a land object "wall surface" existing nearby the player 
object is "forbid" that is to forbid the player object from getting over a wall surface. If a 
"forbid" code, the process returns to the main routine. 

When a control code or action code contained in each polygon constituting the 
wall surface is "climb", the CPU 11 in step S428 causes the player object to perform a 
wall-surface climbing action, as shown in Figure 16. In the Figure 16 example, the player 
object if brought into contact with a wall is put onto the wall surface whereby it is moved 
over the wall surface in response to player's joystick 45 operation. Turning upward the 
joystick 45 causes the player object to climb up the wall surface, while turning it 
downward cause the player object to move down. If the player object moves up to a wall 
surface position where the control code "climb" is not set, the player object can no longer 
lie on the wall surface resulting in fall down. That is, if the wall surface object faced with 
the player object is set with an action code "climb", the player object automatically makes 
an action of climbing up the wall surface. Nevertheless, the moving direction of the 
player object can be determined through the joystick 45. 

Where the control code or action code of the wall surface object is not "forbid" 
and not "climb" and further a floor object in front of a wall surface object is set as default 
with control code "jump", the CPU 11 in step S429 calculates a wall surface height. Thus 
the player object automatically performs its optimal action in accordance with the 
calculated wall surface height, as hereinafter described. 

At first, the CPU 11 determines in step S430 whether or not the calculated wall 
surface height lies within a range of from 0 to 25 cm, i.e., 0 < H ^25 or not. The height 
in this range means very low wall surface. In this case, the player object can get over the 
wall surface as if it went up stairs. Consequently, in the next step S431 the CPU 11 reads 
required animation data out of the external ROM 21, or RAiM 14, for the player object to 
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begin an action "going up stairs" shown in Figure 17. In the Figure 17 example, the wall 
surface to get over is small in height. Accordingly, the player object can get over the 
stairs as a wall surface by an action of treading the stairs step by step according to the 
control code "jump" set in the floor object. In this case, the control code "jump" has 
previously been set in the floor object in front of the wall surface object, or stairs, as 
shown in Figure 17. 

The CPU 11, in the succeeding step S432, determines whether or not the wall 
surface height is in a range of from 25 cm to 50 cm, i.e. 25 < H ^ 50 or not. This range 
of height means a low wall surface. In this case, the player object can get over the wall 
surface by jumping. Accordingly, the CPU 11 in the next step S433 reads required 
animation data out of the ROM 21, or RAM 14, to cause the player object to begin an 
action "jump" shown in Figure 18. In Figure 18 example, the player object jumps at the 
front of the wall surface to land thereon, thus getting over the wall surface. In also this 
case, a control code "jump" has previously been set in a land object, or floor object , in 
front of the wall surface object, as shown in Figure 18. 

In step S434, the CPU 11 determines whether or not the wall surface height is in a 
range of from 50 cm to 100 cm, i.e., 50 < H ^ 100 or not. This range of height means a 
comparatively high wall surface. In this case, the player object can get over the wall 
surface by light climbing. Accordingly, in the next step S435 the CPU 11 reads out 
required animation data to cause the player object to begin an action "light climb" shown 
in Figure 19. In the Figure 19 example of "light climb", the player object'puts his hands 
on the wall surface as an object so that the body is pushed up atop the wall surface through 
a hand's chinning force and a foot's jump force. In this case, a control code "jump" has - 
previously been set in a floor on this side of the wall surface, as shown in Figure 19. 

In step S436, the CPU 1 1 determines whether or not the wall surface height is in a 



range of from 100 cm to 150 cm, i.e. 100 < H ^ 150 or not. This range of height means a 
high wall surface. In this case, the player object can get over the wall surface by usual 
climbing. Accordingly, the CPU 11 in the next step S437 reads out required animation 
data to cause the player object to begin an action "middle climb" shown in Figure 20. In 
the Figure 20 example of "middle climb", the player object responds to a "jump" code 
contained in a floor object in front of the floor, and lightly jumps at the front of the 
objective wall surface put his hand on a wall surface top end. The player object at that 
time is in floating at feet so that the body is lifted to the wall top end only through a hand's 
chinning force. 

In step S438, the CPU determines whether or not the wall surface height is in a 
range of from 150 cm to 250 cm, i.e. 150 < H ^250 or not. This range of height means a 
extremely high wall surface. In this case, the player object can get over the wall surface 
by hard climbing. Accordingly, the CPU 1 1 in the next step S439 causes the player object 
to begin an action "hard climb" shown in Figure 21. In the Figure 21 example of "hard 
climb", the player object responds to a control code "jump" in a floor object in front of the 
objective wall surface, and makes a high jump to put its hand on a wall top end. TTie 
player object at feet is in floating so that the body is lifted to a top wall end through only a 
hand's chinning force. 

In this manner, the CPU 11 detects a control code or action code contained in the 
object data of a land object at or in the vicinity of which the player object is existing, 
whereby the player object is caused to make an action in accord with the control code or 
action code, i.e. wall getting over in the embodiment. It should be noted that, where the 
control code or action code contained in the wall surface object is "climb", getting over 
the wall surface is by "climbing" instead of "jumping" as was explained before. 
Meanwhile, if a "forbid" code is embedded in the wall surface object, the player object is 



not allowed to get over the wall surface. 

Figure 22 shows a subroutine for "door action "shown in step S414 of Figure 9. In 
the first step S440 of Figure 22. the CPU 11 makes reference to the controller data area 
207 of the RAM 14 and determines whether the A button 47A (Figure 1) is being operated 
by the player or not. If the A button 47A is not being operated, the player is determined 
not having an intention to cause the player object enter the door, the process being 
returned as it is to the main routine. 

If "YES" is determined in the step S440, the CPU 11 in the next step S441 makes 
reference to the image data area 205 (Figure 6) and detects a door position from a 
coordinate position of a polygon constituting the door. In the next step S442, the player 
object is corrected in position so that the player object is correctly positioned in a position 
to open the door, based on the door position as detected in the step S441. The corrected 
player object position is recorded in the image data area 205. Thereafter, in step S443 a 
door action is carried out. That is, the CPU 11 reads required polygon data or animation 
data from the image data area 205. to make the player object perform a series of door 
actions (i.e. to grip a knob, open the door, enter the door, and close the door). Figure 23 
illustrates a state that in this door action the player object is going to enter a door. ITiat is, 
in the "door action" to be executed in the step S413 of Figure 9, the player object is 
automatically caused to make a door opening and closing action according to a "door 
code" previously set in a land object shown in Figure 23. 

Incidentally, in the above embodiment explanation was made that the "door" is set 
as a control code or action code in a floor object immediately in front of the door. 
Contrary to this, the "door" code may be set on the door object . 

Figure 24 shows a detail of an action "ladder" to be executed in step S416 of 
Figure 9. In the first step S444 of Figure 24, the image data area 205 (Figure 6) is referred 
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to deteaaladderposhionfromacoordtaatc position otapolygo,,co„3.totmg the ladder 
In .he „ex, «ep S445, .he player objec, « corrected i„ position such that player object U 
positioned at the foot of the ladder, based on a ladder position detected by the step S444. 
The corrected player object position is recorded in the image data area 205. Thereafter, in 
the step S446 a ladder aaion is carried out. Hat is. the CPU U reads required polygon 
data or anitnation data from the image data 205. and causes the player object to perfonn a 
sedes of a ladder-climbing action, i.e. to put hands and feet on the Udder and altemately 
move left and right hands and feet on the ladder. Figure 25 illustrates a state that the 
player object goes up the ladder to a midway thereof. That is, for the "ladder action" to be 
e.xecuted in step S416 of Figute 9, the player object is automatically caused to perfonn a 
ladder climbing according to a "ladder" code previously set in a land object shown in 
Figure 25, i.e. wall surface object. 

Explaining in greater detail, in the Figure 25 embodiment no control code "step 
off' has been set in the floor object in front of the wall surface object constituting the 
ladder. Accordingly, the player object can make a "ladder climb" action according to a 
control code "ladder" for the wall surface object. TT^at is, there is no affection on the 
ladder climb action unless the control code in the floor object is on "step off. If a 
"ladder" code is set on the wall surface, the player object when facing the wall surface 
with the ladder automatically grips the ladder. Thereafter, the player object goes up the 
ladder if the player tilts the joystick 45 (Figure 1) up, and comes down if it is tilted down. 
If the player object reaches an uppermost position of the ladder, the player object 
automatically steps on a floor close thereto. Meanwhile, if the player object comes from 
the upper floor to the ladder an "enter ladder" code set in a wall surface object on the back' ' 
of the ladder is detected so that the player object can go down the ladder according to the 



code. 
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In this manner, according to this embodiment, it is possible to cause the player 
object to automaticaUy make a different action depending upon a control code or action 
code previously contained in a land object where the player object exists. Accordingly, 
program setting is very easy to control the action of the player object. 

Incidentally, a flowchan shown in Figure 26 represents a player object processing 
operation for the step S5 of the main routine of Figure 7. In the first step S501, the CPU 
1 1 determines whether the player object is in a course of action or not. If in a course of 
action, a position and pose of the player object are determined so that the player object 
continues its action. The pose is determined by animation data as was explained before. 

If the player object is not in a course of action, the CPU 11 in the following step 
S503 detects an operation state of the joystick 45 (Figure 1, Figure 4) included in the 
controller 40. Subsequently, a moving direction, moving speed and position and pose of 
the player object are determined respectively in steps S503, S504 and S505, according to 
an operation state of the joystick 45. In step S507, the player object is registered to the 
display list area 201 (Figure 6) of the RAM 14, similarly to the case after passing through 
the step S502. In response, the player object is to be displayed depending upon the 
joystick 45 operation state. 

The camera determination process in the step S6 of the Figure 9 main routine is 
explained in detail with reference to Figure 27 as well as the related figures. In the first 
step S601 of Figure 27, the CPU 11 makes reference to the data in the image data area 
205, and detects a control code (camera code) previously set in the object data of a land 
object existing underneath the player object. In each of steps S602, S604, S606, S608 and 
S610, it is determined whether the detected control code is a first camera code, second 
camera code, third camera code, fourth camera code or fifth camera code. 

Explanation is made herein on a first camera, second camera, third camera, fourth 
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camera, and fifth camera which have been placed in the virtual three dimensional space in 
the embodiment, based on Figure 28. In an example of Figure 28, a longitudinal waU is 
provided in almost a center of a space that is rectangular in plan, wherein a door is formed 
on one pan of the wall. A third camera is fixedly set up on one side of the door (on side of 
door opening) which is directed to the door. On an opposite side to the door, a fourth 
camera is set up. This fourth camera is provided as a zoom camera to take a player object 
that is going to open and enter the door. Furthermore, a second camera and fifth camera 
are individually, fixedly set up at two respective comers in the space. The first camera is 
provided as a movable camera which is allowed to move following the player object. 
Camera control is explained below on an assumption of this embodiment having the five 
virtual cameras in the three dimensional space as above. However, it is needless to say 
that the number, arrangement and function or roll (fixing, moving, zooming, etc.) can be 
appropriately modified as required. 

Note that in Figure 28 the terms "first camera", "second camera", "fifth 
camera" given in blocks (rectangular lattices) respectively represent control codes, or 
camera codes, previously having been set in the land objects of this three dimensional 
space. Consequently, when the player object is existing in one block, the player object 
will be taken by a camera corresponding to a camera code having been set on that block. 

Referring back to Figure 27, if a first camera code is detected in step S602, then in 
the following step S603 a first camera control program is selectively set. The camera 
control program, as explained before, is set in the camera control program' area 22f 
(Figure 5) of the external ROM 21, which is transferred as required to the program area 
202 of the internal RAM 14. Accordingly, the CPU 11 in step S603 reads a first camera 
control program out of the program area 202 (Figure 6). 

The first camera control program is a control program for the first camera, and the 
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first camera is arranged to move following the player object as described before. In the 
first camera control program detailed in Figure 29, in step S612 the data in the image data 
area 205 (Figure 6) is first referred to detect a position of the player object. In the next 
step S613, the CPU 11 determines a position of the first camera such that the distance 
fi-om the player object to the first camera becomes constant. In step S614 the first camera 
is directed of picture taking direction to the player object. Accordingly, the first camera is 
to take a player object-back view with a constant distance. 

In a second camera control program to be executed in step S605 (Figure 27), in the 
first step S615 a position of the player object is detected as shown in Figure 31, similarly 
to the former step S612 (Figure 29). Then, in step S616, the second camera is directed of 
picture taking direction to the player object. That is, the second camera is to take the 
player object from a fixed position shown in Figure 28. 

Incidentally, because the fifth camera is a fLxed camera likewise the second 
camera, a fifth camera control program to be selected in step S6 11 is similar to the second 
camera control program of Figure 31. 

The third camera is fixedly set up in front of the door as was shown in Figure 28. 
Accordingly, the third camera is to merely take the player object entering or exiting the 
door from a constant distance point. Due to this, the third camera control program of step 
S607 (Figure 27) includes the step S617 of Figure 32. la this step S617 the third camera 
is directed of picture taking direction to the door. Accordingly, the manner the player 
object is entering or exiting the door will be taken by the third camera, as shown in Figure 
33. 

Figure 34 shows a detail of a fourth camera control program to be executed in step ' 
S609 of Figure 27. The fourth camera is chosen, as will be well understood from Figure 
28, when detected is a fourth camera code having been set on a block to which the player 
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object has entered. In the first step S618 of Figure 34, the number of frames is detected 
after detecting a fourth camera code and step S609 is entered, i.e. after camera change 
over. This is because there are two ways in which the fourth camera takes the player 
object. If the number of the frames is less than a predetermined number , i;e. when 
immediately after camera change over, "YES" is detennined in step S619. In this case, 
the CPU 11 in step S620 controls the fourth camera such that the fourth camera takes, 
from a predetermined position, the player object entering the door. The player object 
taken by the fourth camera in the step S620 is illustrated in Figure 35. As will be 
understood from Figure 35, the fourth camera fixedly provided at the position shown in 
Figure 28, in the step S620 wherein at immediately after camera change over, takes as a 
distant view the player object entering the door. That is, the fourth camera takes a 
comparatively wide range including the player object. Consequently, where the player 
object is entering the door as in this embodiment, from overall-view display the player 
can readily understand where the player object as a hero is now existing. 

Before elapsing a predetermined number of frames or time from the camera 
change over but not immediately after that camera change over, "NO" is determined in 
step S621. In this case, in the following step S622 the CPU 11 causes the fourth camera 
to zoom up in order to take as a close-range view the player object, as shown in Figure 36. 
That is, the picture taking is in a comparatively narrow range but including the player 
object. 

If a predetermined number of frames has elapsed, "YES" is determined in the step 
S621. In this case, the CPU 11 switches from the fourth camera over to the first camera, 
as shown in step S623. 

In this manner, according to this embodiment, it is possible to automatically 
switch over the camera to take the player object and its function depending upon a control 
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code, or camera code, previously contained in a land object where the player object is 
existing. Consequently, even where troublesome camera switching is necessary, it is very 
easy for a program to set up therefor. Meanwhile, where the camera is switched 
depending upon a position of the player object PC-Y coordinate position), camera 
switching if same in X-Y coordinate is effected similar irrespective of a Z coordinate, or 
height. On the contrary, in the method of this embodiment the camera switching codes 
are embedded in the land objects. Accordingly, in the case of in a same X-Y plane but 
different in height (Z), it is possible to set a different land object, i.e. camera code, and 
hence a differenct camera. Tliat is, in the embodiment, camera switching is feasible in a 
three dimensional fashion. 

Incidentally, after ending any of the steps S620, S622 and S623, the process 
returns to the main routine. 

Referring to Figure 37, the explanation is made in detail on the step S9 of the 
Figure 7 main routine, i.e. sound processing. TTiis sound processing utilizes the control 
codes explained before. Consequently, in the first step S624 of Figure 37, reference is 
made to the image data area 205 to detect a control code, or melody code, set on a land 
object where the player object is existing thereon. In step S625, it is determined whether 
the control code, or melody code, is on BGMl or not. The melody code BGMl is a code 
to select a first BGM (Back-Ground ). Consequently, after «YES" is determined in step 
S625, the CPU 11 in step S626 reads melody or sound data for the first BGM out of the 
sound memory area 206 shown in Figure 6, and output it to the bus control circuit 121 
(Figure 2). 

If "NO" is determined in step S625, it is determined in step S627 whether or not 
the control code, or melody code, is for BGM2. The melody code BGM2 is a code to 
select a second BGM. Accordingly, after "YES" is determined in step S627, the CPU 1 1 
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in step S628 reads melody or sound data for the second BGM out of the sound memory 
area 206, and outputs to the bus control circuit 121. 

After "NO" is determined in both steps S625 and S627, the CPU 11 in step S629 
determines whether the control code, or melody code, is for "outcry" or not. The melody 
code "outcry" is a code to generate a effect sound of outcry. Consequently, after "YES" 
is determined in the step S629, the CPU 11 in step S630 reads sound data for "outcry" out 
of the sound memory area 206, and outputs it to the bus control circuit 21. 

Incidentally, when the control code or melody code or sound code is different 
from the ones described above, then in step S631 another one of sound data is set up. 

In this manner, according to this embodiment, it is possible to automatically 
switch the sound to generate it in accordance with a control code, or sound code, 
contained in a land object where the player object exists. Accordingly, even where 
troublesome control is necessary for switching sound, it is easy for a program to set up 
therefor. 

Although the present invention has been described and aiustrated in detail, it is 
clearly understood that the same is by way of illustration and example only and is not to 
be taken by way of limitation, the spirit and scope of the present invention being limited 
only by the terms of the appended claims. 
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